MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 107

Text File | 1995-08-13 | 61KB | 1,728 lines

C.S.M.P. Digest             Sat, 12 Aug 95       Volume 3 : Issue 107

Today's Topics:

        Clipping controls
        Is a volume from server X mounted?
        MDEF and PowerPC
        Prefs in resource fork
        TextBox & Transfer Mode?!
        WOW. Was: Man, is image manipulation ugly in Pascal!
        [ANN][PTR] Advanced Color Imaging for Toolbox Assistant



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Gregory Lo)
Subject: Clipping controls
Date: Tue, 18 Jul 1995 00:14:10 -0400
Organization: Queen's University

How do you go about drawing controls within a clipped area?

I set the clip region with ClipRect, but the controls only seem to obey
the clipping some of the time.

What is the deal with SetClip and GetClip.  IM-I tells me that SetClip and
GetClip don't actually set the ClipRgn itself, but rather make copies
of/to it.  So, then how can one make use of these routines safely, and
what effect does ClipRect have in conjunction with SetClip and GetClip?

GLo

- ---------------------------------------------------------
Gregory Lo  GLo ?:^(>      <mailto:[e-mail]>
<mailto:[e-mail]>      <mailto:[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Wed, 19 Jul 1995 12:53:58 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>,
[e-mail] (Gregory Lo) wrote:
>
> How do you go about drawing controls within a clipped area?
>
> I set the clip region with ClipRect, but the controls only seem to obey
> the clipping some of the time.
>
> What is the deal with SetClip and GetClip.  IM-I tells me that SetClip and
> GetClip don't actually set the ClipRgn itself, but rather make copies
> of/to it.  So, then how can one make use of these routines safely, and
> what effect does ClipRect have in conjunction with SetClip and GetClip?
>
> GLo
>
> -----------------------------------------------------------
> Gregory Lo  GLo ?:^(>      <mailto:[e-mail]>
> <mailto:[e-mail]>      <mailto:[e-mail]>

GetClip gives you a duplicate of the ClipRgn so that, if you need to
change the clipRgn you can then restore it, ie.

RgnHandle saveRgn;
saveRgn = NewRgn();
GetClip(&saveRgn);
SetClip(specificRgn);           //      previously allocated and defined rgn
//do some drawing
SetClip(saveRgn);

This is useful if, say, you're drawing a graph and want to clip to the
graph axes, but you still want window updates to occur outside this
region..

GetClip(&saveRgn);   // clipRgn was initially the portRect
ClipRect(&graphRect);
DrawGraph();
SetClip(saveRgn);

As far as the controls go, I don't know why you're having problems
since you don't describe the symptoms.  Could be though a radio button
with a title field that extends past the boundary of the clip region
you're trying to set up, or else some CDEF that plays with the clip
region internally for its own nefarious purposes!

Dave Stone

+++++++++++++++++++++++++++

>From [e-mail] (Gregory Lo)
Date: Thu, 20 Jul 1995 08:54:08 -0400
Organization: Queen's University

In article <[e-mail]>,
[e-mail] (David Stone) wrote:

> GetClip gives you a duplicate of the ClipRgn so that, if you need to
> change the clipRgn you can then restore it, ie.
>
> RgnHandle saveRgn;
> saveRgn = NewRgn();
> GetClip(&saveRgn);
> SetClip(specificRgn);           //      previously allocated and defined rgn
> //do some drawing
> SetClip(saveRgn);
>
> This is useful if, say, you're drawing a graph and want to clip to the
> graph axes, but you still want window updates to occur outside this
> region..
>
> GetClip(&saveRgn);   // clipRgn was initially the portRect
> ClipRect(&graphRect);
> DrawGraph();
> SetClip(saveRgn);

Thanks, this helps a lot!  I didn't know that the Rgn you passed as an
argument to GetClip() had to already be allocated with NewRgn().  I'm not
sure about having to pass the pointer to a RgnHandle, though...

But, what about ClipRect() ???  Does it totally replace the existing clip
region with a rectangle?  Does it add a rectangle to the clip region?

And are you still responsible for disposing of the Rgn you pass to SetClip() ??
Does it copy the contents of your Rgn to the clip region?  Does is
completely replace the clip region with your Rgn?  Does it merely replace
the handle stored in the GrafPort with your handle, leaving the old clip
region handle leaking?

> As far as the controls go, I don't know why you're having problems
> since you don't describe the symptoms.  Could be though a radio button
> with a title field that extends past the boundary of the clip region
> you're trying to set up, or else some CDEF that plays with the clip
> region internally for its own nefarious purposes!

I don't know if the CDEF is acting up, but what I do is call ClipRect(),
and part of the control still draws outside of the clipped region.
Strange.  I usually do this drawing during while handling an update
event.  I should check my code for other instances where I draw controls,
or whatever.

GLo

- ---------------------------------------------------------
Gregory Lo  GLo ?:^(>      <mailto:[e-mail]>
<mailto:[e-mail]>      <mailto:[e-mail]>

- ---BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQA/Ai8+AVAAAAEBgMIk5CmBwL3pO1Nb164GoQsAImsTKFL5V9q/Gwdz8AJRrMoM
DyCDCBZvUsNweh0gWQARAQABtCNHcmVnb3J5IExvIDwzZ2wyMUBxbGluay5xdWVl
bnN1LmNhPrQmR3JlZ29yeSBMbyA8M2dsMjFAamVmZi1sYWIucXVlZW5zdS5jYT60
IkdyZWdvcnkgTG8gPGxvZ0BkZWNsYWIucXVlZW5zdS5jYT4=
=Hw55
- ---END PGP PUBLIC KEY BLOCK-----

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 20 Jul 1995 15:48:53 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] writes:
> [ ... ]
>But, what about ClipRect() ???  Does it totally replace the existing clip
>region with a rectangle?  Does it add a rectangle to the clip region?

ClipRect() replaces the clipRgn of the current GrafPort with a rectangular
region described by the given Rect.

>And are you still responsible for disposing of the Rgn you pass to SetClip() ??

Yes.

>Does it copy the contents of your Rgn to the clip region?

Yes.

>Does is completely replace the clip region with your Rgn?

Yes. The new clipRgn will be _exactly_ the region you give ClipRgn(), not
the intersection of the region you pass and the current clipRgn (or
anything like that).

>Does it merely replace
>the handle stored in the GrafPort with your handle, leaving the old clip
>region handle leaking?

No. ClipRgn() changes the current clipRgn so that it describes the same
region as the region you pass to ClipRgn(). (Try saying that five times
fast ;-). After ClipRgn() returns, the region you passed in is yours to
play with and dispose of with no further effect on the clipRgn (unless
you call ClipRgn() again, of course). No leak.

>I don't know if the CDEF is acting up, but what I do is call ClipRect(),
>and part of the control still draws outside of the clipped region.
>Strange.  I usually do this drawing during while handling an update
>event.  I should check my code for other instances where I draw controls,
>or whatever.

That is odd. Most of the CDEFs that I've seen (and all that I've written) set
the clipping region to the intersection of the current clipping region with
their control's rectangle before they do any drawing. This way, both the
clipping region of the current port and the control's rectangle are respected.
Is this one of the system's CDEFs or is it 3rd party?

Doing the control drawing during the update handling process shouldn't be a
problem. All BeginUpdate() does is replace the clipping region with the
intersection of the clipRgn and visRgn (so that drawing takes place only
in the _visible_ portion of the window). This shouldn't be increasing the
size of the clipRgn; it should only make it smaller so I don't think that's
the problem.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Fri, 21 Jul 1995 13:02:26 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>,
[e-mail] (Gregory Lo) wrote:
>
> In article <[e-mail]>,
> [e-mail] (David Stone) wrote:
>
> > GetClip gives you a duplicate of the ClipRgn so that, if you need to
> > change the clipRgn you can then restore it, ie.
> >
> > RgnHandle saveRgn;
> > saveRgn = NewRgn();
> > GetClip(&saveRgn);
> > SetClip(specificRgn);           //      previously allocated and defined rgn
> > //do some drawing
> > SetClip(saveRgn);
======snip======
>
> Thanks, this helps a lot!  I didn't know that the Rgn you passed as an
> argument to GetClip() had to already be allocated with NewRgn().  I'm not
> sure about having to pass the pointer to a RgnHandle, though...
>

My mistake - I was going from memory and got confused with GetPort..
GetClip(saveRgn);

> But, what about ClipRect() ???  Does it totally replace the existing clip
> region with a rectangle?  Does it add a rectangle to the clip region?
>

It's a bit like calling RectRgn(specificRgn,&specificRect) before calling
SetClip, but saves you the bother.

> And are you still responsible for disposing of the Rgn you pass to SetClip() ??

Yes

> Does it copy the contents of your Rgn to the clip region?  Does is
> completely replace the clip region with your Rgn?  Does it merely replace
> the handle stored in the GrafPort with your handle, leaving the old clip
> region handle leaking?

Completely replaces it with a copy of your region

Dave Stone

---------------------------

>From [e-mail] (John M. Sully)
Subject: Is a volume from server X mounted?
Date: Wed, 26 Jul 1995 09:59:11 -0500
Organization: Case Western Reserve University

I've been stumped by this for a while so I'm hoping that someone might be
able to help me.

I am trying to write some code that will tell me if a volume from a
specific AppleShare server is mounted.
I'm not really concerned with which volume it is, just if is from the
server I'm looking for.  The reason
behind this is we have multiple servers that are acting as our campus
software libraries and I am writing a
launching program that will choose from these servers randomly.  I don't
want to waste connections by
connecting to more than one server at a time, but I don't necessarily know
all the volume names on each
server (and I don't want to hardcode a list of 'known' volumes in the
code...makes it difficult if we change
things).

What I have tried in the past is use PGHGetVInfo to get the vRefNum of
each mounted volume and then
call PBgetVolMountInfo on that vRefNum and look at the server name in the
AFPVolMountInfo
record.  Unfortunately, PGGetVolMountInfo seems to crash the machine when
called against
local volumes (hard disks, etc) which is a little inconvenient.

Can anyone offer any suggestions?

later...
John

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 27 Jul 1995 09:58:38 +0800
Organization: Department of Computer Science, University of Western Australia

In article <[e-mail]>,
[e-mail] (John M. Sully) wrote:

>I am trying to write some code that will tell me if a volume from a
>specific AppleShare server is mounted.

Why not just make an alias to each volume in turn and then call
GetAliasInfo on it to see which server/zone it's from?

Share and Enjoy.
--
Quinn "The Eskimo!"      "Space army! I'd death ray my grandmother
                          for a space army about now."

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 29 Jul 1995 02:09:25 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (John M. Sully) wrote:

>What I have tried in the past is use PGHGetVInfo to get the
>vRefNum of each mounted volume and then call PBgetVolMountInfo
>on that vRefNum and look at the server name in the
>AFPVolMountInfo  record.  Unfortunately, PGGetVolMountInfo seems
>to crash the machine when called against local volumes (hard
>disks, etc) which is a little inconvenient.

As pointed out in the Tech Note "Inside Macintosh: Files - Errata", you
have to initialize the ioNamePtr field in the parameter block you pass to
PBGetVolMountInfoSize and PBGetVolMountInfo (that field was left out in
IM: Files). If you don't initialize it to a nil pointer or point it to a
full pathname pString, you may end up crashing the system with a bus error
or an address error (or maybe just a hang).

- Jim Luther

---------------------------

>From [e-mail] (Tina Marie)
Subject: MDEF and PowerPC
Date: 12 Jul 1995 09:22:42 -0500
Organization: NeoSoft Internet Services   [phone]


I've got some old code that uses a custom MDEF (not in a resource),
by building a handle containing a JMP and then the address of the
function.  This works great on 68K machines, but obviously crashes
hard when I compile for PowerPC (it doesn't know what to do with
the 68K JMP).

So, short of doing the Right Thing and putting the MDEF in a resource
(which I'd rather not do), how do I make this work on PowerPC? I
don't think it's as easy as just changing the 68K JMP to a PPC JMP,
is it??  I assume I have to make a proc pointer as well...but no
matter what I do, it still crashes.

E-mail is very much appreciated!

Tina Marie
programmer, Kaetron Software

--
"God uses longints"     -  Cecil H.
In Fortran, God is real unless declaired integer.

http://starbase.neosoft.com/~tina

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Thu, 13 Jul 1995 16:22:07 -0700
Organization: Altura Software, Inc.

In article <3u0lri$[e-mail]>, [e-mail]
(Tina Marie) wrote:
> So, short of doing the Right Thing and putting the MDEF in a resource
> (which I'd rather not do), how do I make this work on PowerPC? I
> don't think it's as easy as just changing the 68K JMP to a PPC JMP,
> is it??  I assume I have to make a proc pointer as well...but no
> matter what I do, it still crashes.

One solution is to put the address of a RoutineDescriptor instead of the
68K jump and hard address.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Coming to you fast as lightning on a 9500/120!

+++++++++++++++++++++++++++

>From [e-mail] (Rmeadows)
Date: 25 Jul 1995 13:04:15 -0400
Organization: America Online, Inc. (1-800-827-6364)

This is how I set it up:

I create a type:
typedef struct tJumpRecord {
#if !__powerc
 short instruction;     // JMP  function
 void (*function)();
#else
 long     lea;    // LEA  PC+8,A0
 short     movea_l;   // MOVEA.L (A0),A0
 short     jmp;    // JMP  (A0)
 UniversalProcPtr function;
#endif // !__powerc
} JumpRecord, **JumpHandle;

...and then I use a macro to initialize the jump record, so that I can use
the same code for PPC and 68k:
#if !__powerc
 #define mInitJumpRecord(jumpHdl, procPtr) { (**jumpHdl).instruction =
0x4EF9; \
                 (**jumpHdl).function = procPtr;  \
                }
#else
 #define mInitJumpRecord(jumpHdl, univProc) { (**jumpHdl).lea =
0x41FA0006;  \
                 (**jumpHdl).movea_l = 0x2050;  \
                 (**jumpHdl).jmp = 0x4ED0;   \
                 (**jumpHdl).function = univProc; \
                }
#endif // !__powerc

This works for MDEFs and LDEFs, and probably just about any other xDEF.

HTH...
randy
FGM, Inc.
[e-mail]

---------------------------

>From [e-mail] (Clive Wilson)
Subject: Prefs in resource fork
Date: Tue, 04 Jul 1995 21:45:41 -0200
Organization: Chez Moi

Is there any easy way of having a small number of preferences stored in
the resource fork of an application?

I'm using THINK Pascal and really don't want to have to have the hassle of
hunting the Preferences folder for my prefs. In any case it's more robust
having them located with their application.

If there is a way of doing this, I would be really grateful if someone
could suggest some means of doing it.

Many thanks in anticipation,

Clive Wilson

+++++++++++++++++++++++++++

>From [e-mail] (Will Scullin)
Date: 05 Jul 1995 21:31:39 GMT
Organization: University of Illinois at Urbana

In article <[e-mail]> [e-mail] (Clive Wilson) writes:

> From: [e-mail] (Clive Wilson)
>
> Is there any easy way of having a small number of preferences stored in
> the resource fork of an application?
>
> I'm using THINK Pascal and really don't want to have to have the hassle of
> hunting the Preferences folder for my prefs. In any case it's more robust
> having them located with their application.

Well... not necessarily. Applications that as used over AppleShare may
not behave as expected if their preferences are stored in their resource
fork, and if the software is updated, an updater application must be
used to copy the resource.

Will
--
| Will Scullin                                  |
| University of Illinois                        |
| [e-mail]                           |
| http://www-pablo.cs.uiuc.edu/~scullin/        |

+++++++++++++++++++++++++++

>From [e-mail] (Paul J. Rodman)
Date: Wed, 05 Jul 1995 18:14:16 -0700
Organization: Marginal at best

In article <[e-mail]>,
[e-mail] (Will Scullin) wrote:

> > From: [e-mail] (Clive Wilson)
> >
> > Is there any easy way of having a small number of preferences stored in
> > the resource fork of an application?
> >
> > I'm using THINK Pascal and really don't want to have to have the hassle of
> > hunting the Preferences folder for my prefs. In any case it's more robust
> > having them located with their application.
>
> Well... not necessarily. Applications that as used over AppleShare may
> not behave as expected if their preferences are stored in their resource
> fork, and if the software is updated, an updater application must be
> used to copy the resource.

Additionally, if the application is used over a network by more than one
user at a time, the wheels might just fall off.

I would say that having your prefs stored in the "usual" place is (a) very
robust and (b) very little hassle.  The code is just a few lines.

____________________________________________________________
Paul J. Rodman                         [e-mail]
____________________________________________________________

+++++++++++++++++++++++++++

>From Richard Wesley <[e-mail]>
Date: 6 Jul 1995 03:14:08 GMT
Organization: Punch Deck Consulting

[e-mail] (Clive Wilson) wrote:
>Is there any easy way of having a small number of preferences stored in
>the resource fork of an application?
>

Not recommended.  What if your app is on a server? Or a CD-ROM?!

>I'm using THINK Pascal and really don't want to have to have the hassle of
>hunting the Preferences folder for my prefs. In any case it's more robust
>having them located with their application.
>

Why is it "more robust"?  You can't run the thing from read-only media
and it can't be shared among multiple users.

What's so hard about:

CONST

STRn_FileNames = 128;
kPrefsFileName = 1;
kPrefsCreator = 'mypr';
kPrefsFileType = 'myap'; { Don't call it 'pref'!  See develop article.}

VAR

e : OSErr;
fileName : Str255;
spec : FSSpec;
fRefNum : Integer;

BEGIN

GetIndString (fileName, STRn_FileNames, kPrefsFileName);
e := FindFolder (kOnSystemDisk, kPreferencesFolder, kCreateFolder, spec.vRefNum, spec.parID);
e := FSMakeFSSpec (spec.vRefNum, spec.parID, fileName, spec);
IF (e <> noErr) THEN
    e := FSpCreate (spec, kPrefsCreator, kPrefsFileType, smDefaultScript);
fRefNum := FSpOpenResFile (spec, fsRdWrPerm);

END;

>If there is a way of doing this, I would be really grateful if someone
>could suggest some means of doing it.

Try the above.  Apologies if my PASCAL is a bit rusty...

- rmgw

http://www.punchdeck.com/hawkfish/Resume.html

- --------------------------------------------------------------------------
Richard Wesley  [e-mail] | "'Hand it round first, and cut it
Punch Deck Consulting [e-mail] |  afterwards.'" - Lewis Carroll,
     Macintosh Software Development    |    "Through the Looking Glass"
- --------------------------------------------------------------------------



+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: 6 Jul 1995 13:34:06 GMT
Organization: The Pitt, Chemistry

In article <[e-mail]>,
[e-mail] (Clive Wilson) wrote:

>Is there any easy way of having a small number of preferences stored in
>the resource fork of an application?
>
>I'm using THINK Pascal and really don't want to have to have the hassle of
>hunting the Preferences folder for my prefs. In any case it's more robust
>having them located with their application.



    Hmmm... your apps resource fork is a good place to keep a
      read only copy of your default preferences, then just
      copy it whole into your apps pref file on file creation,
      but I would not suggest keeping user prefs there.

    You increase the chance of corrupting the application, some
      folks lock their apps to reduce this risk and so will have
      problems when you try and write to it, you can't save
      preferences on a CD rom or locked remote server, or worse
      you can change preferences for your whole work group.

    I'd stick with the pref file if possible.  There was an article
      re: pref file propriety and eg. code in develop 18.  Some
      folks didn't quite agree with all the authors opinions on
      what was "the right way" to do prefs, but the code and
      general discussion should be useful (you can DL eForm
      copies of develop from ftp.support.apple.com).  Luck,


 ---------------------= Nicholas C. DeMello =--------------------

 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] (Jim Nash)
Date: 6 Jul 1995 15:14:18 GMT
Organization: SRS

In article <[e-mail]>,
[e-mail] (Clive Wilson) wrote:

> Is there any easy way of having a small number of preferences stored in
> the resource fork of an application?
>
> I'm using THINK Pascal and really don't want to have to have the hassle of
> hunting the Preferences folder for my prefs. In any case it's more robust
> having them located with their application.

Here is example code for accessing a preference file in the system
folder.  It is specialized to my application so you will have to delete
unwanted code and references to data structures.

 function OpenPrefFile (name: Str255): integer;
{Gets user preference file from the preferences folder in the System folder}
{The preferences are strings in which a word is followed by a parameter list}
  var
   err: OSErr;
   vRef, refnum: integer;
   dirID: longint;
   spec: FSSpec;
 begin
  with user^ do begin
   err := FindFolder(kOnsystemDisk, kPreferencesFolderType, kCreateFolder,
vRef, DirID);
   if err = noErr then
    err := FSMakeFSSpec(vRef, dirID, name, spec);
   if (err = noErr) or (err = -43) then begin
    refnum := FSpOpenResFile(spec, fsCurPerm);
    if refnum < 0 then begin
     FSpCreateResFile(spec, creator_OSname, 'xxxx', iuSystemScript);
     err := ResError;
     if err <> noErr then begin
      err := FSpCreate(spec, creator_OSname, 'xxxx', iuSystemScript);
      FSpCreateResFile(spec, creator_OSname, 'xxxx', iuSystemScript);
      err := ResError;
     end;
     refnum := FSpOpenResFile(spec, fsCurPerm);
    end;
   end;
  end;
  OpenPrefFile := refnum;
 end;


 procedure GetConfigFile;
  const
   name = 'Synapse Configuration';
  var
   err: OSErr;
   count, i, j, refnum, index: integer;
   sp: StringHandle;
   str, wrd: Str255;
 begin
  refnum := OpenPrefFile(name);
  if refnum > 0 then begin
   count := CountResources('xxxx');
   for i := 1 to count do begin
    sp := StringHandle(GetIndResource('xxxx', i));
    if sp <> nil then begin
     str := sp^^;
     ReleaseResource(handle(sp));
     GetNextWord(str, wrd);
     if wrd = 'Shutter' then begin
      GetComInteger(str, j);
      user^.ImgOpt.useShutterType := j;
     end;
     if wrd = 'filterZero' then begin
      GetComInteger(str, j);
      user^.ImgOpt.filterZero := j;
     end;
     if wrd = 'filterOffset' then begin
      GetComInteger(str, j);
      user^.ImgOpt.filterOffset := j;
     end;
    end;
   end;
  end;
 end;


 procedure PutConfigFile;
  const
   name = 'Synapse Configuration';
  var
   err: OSErr;
   index, count, i, refnum: integer;
   sp: StringHandle;

  procedure MyAddStrResource (str: Str255);
   var
    sp: StringHandle;
  begin
   sp := StringHandle(NewHandle(length(str) + 1));
   sp^^ := str;
   index := index + 1;
   AddResource(handle(sp), 'xxxx', index, str);
   err := ResError;
  end;

 begin
  refnum := OpenPrefFile(name);
  if refnum > 0 then begin
   count := CountResources('xxxx');
   for i := 1 to count do begin
    sp := StringHandle(GetIndResource('xxxx', i));
    err := ResError;
    if sp <> nil then begin
     RmveResource(handle(sp));
     err := ResError;
    end;
   end;
   index := 127;
   MyAddStrResource(concat('Shutter  ', itos(user^.ImgOpt.useShutterType)));
   MyAddStrResource(concat('filterZero  ', itos(user^.ImgOpt.filterZero)));
   MyAddStrResource(concat('filterOffset  ', itos(user^.ImgOpt.filterOffset)));
  end;
 end;

Good Luck.

- Jim

____________________________________________________________________
James W. Nash, Synergistic Research Systems
4409 Mahan Court, Silver Spring, MD 20906, USA
[phone], fax: [phone]
____________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hubauer)
Date: Thu, 06 Jul 1995 23:00:17 -0400
Organization: MSA

In article <[e-mail]>,
[e-mail] (Clive Wilson) wrote:

> Is there any easy way of having a small number of preferences stored in
> the resource fork of an application?
>
> I'm using THINK Pascal and really don't want to have to have the hassle of
> hunting the Preferences folder for my prefs. In any case it's more robust
> having them located with their application.
>
> If there is a way of doing this, I would be really grateful if someone
> could suggest some means of doing it.
>
> Many thanks in anticipation,


Maybe I'm silly, but this is how I (and most everyone I work with) view
resources as preferences:

>From exprience, I do not trust the resource manager to write resources.
Anytime I have written a program that writes resources (for preferences or
whatever), The resource fork has eventually become corrupted.  (Have you
ever had a tech support person tell you to "try trashing your prefs and
restart"?)

I view resources as READ ONLY.  I would strongly recomend storing your
preferences in the data fork.

Bill Hubauer
MSA

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: 7 Jul 1995 12:35:12 GMT
Organization: zercom technologies inc.

In article <[e-mail]>,
[e-mail] (Clive Wilson) wrote:

> Is there any easy way of having a small number of preferences stored in
> the resource fork of an application?
>
> I'm using THINK Pascal and really don't want to have to have the hassle of
> hunting the Preferences folder for my prefs. In any case it's more robust
> having them located with their application.
>
> If there is a way of doing this, I would be really grateful if someone
> could suggest some means of doing it.
>
> Many thanks in anticipation,
>
> Clive Wilson

Storing prefs in your app would be unadvisable for many reasons.  Those at the top of my head are that the user may be running the software off a locked volume, or a shared environement.  Shall the user's machine freeze for some reason while your software is playing with itself may cause some irreparable dammages to the application (AND preferences data), forcing the user to re-install the app and reset the preferences (no matter how small prefs are, I've noted users hate having to set them again).

Here's code you can use to easilly locate a pref file in the preferences folder:

        OSErr           osErr           =   noErr;
        FSSpec          prefFileSpecs;
        short           foundVRefNum    =   0;
        long            foundDirID      =   0;

        osErr   =   FindFolder( kOnSystemDisk,
                                kPreferencesFolderType,
                                kCreateFolder,
                                &foundVRefNum,
                                &foundDirID);

        if (osErr == noErr) {

            osErr = FSMakeFSSpec(   foundVRefNum,
                                    foundDirID,
                                    (unsigned char*) "\My Pref File Name",
                                    &prefFileSpecs);
        }


At this point, all you have to do is open your pref file resource fork with

    osErr = FSpOpenResFile(&prefFileSpecs, fsCurPerm);

and you've got your prefs at hand.
--
Martin-Gilles Lavoie

MPW: Because life is too complicated for CodeWarrior.
--MGL

+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Fri, 07 Jul 1995 13:40:08 -0700
Organization: Apple Computer

In article <[e-mail]>,
[e-mail] (Clive Wilson) wrote:

> Is there any easy way of having a small number of preferences stored in
> the resource fork of an application?

Are you asking for details on how to add resources to your application's
rsrc fork while it's running?

> I'm using THINK Pascal and really don't want to have to have the hassle of
> hunting the Preferences folder for my prefs. In any case it's more robust
> having them located with their application.

Saving preferences externally should not be considered a hassle, it should
be considered a requirement if you have user preferences.  Is your app
never going to be run from a server that might have read-only access on
it?  Is you app never going to be used in an educational environment?  Is
your app never  going to be on a drive someone is backing up with
utilities like Retrospect?  There's more I'm sure.  If you can answer yes
to any of those, then go right ahead and save your prefs in the
application itself.  Among the many reasons why you should use the
Preferences folder, by two favorite are:

1. Backup utilities won't be saving your entire application every night
because the mod date on it is constantly being updated because prefs are
being saved in it.
2. Upgrading to newer versions of your software don't wipe out the users
preferences they had setup in the earlier version (unless of course
preference data structures changed or something like that).

> If there is a way of doing this, I would be really grateful if someone
> could suggest some means of doing it.

Assuming you're familiar with creating handles, simply call AddResource()
on it making sure the current res file is your app's (which it will be
unless you've changed it).  Do a Get1Resource() on the pref type you
created, and if it's not there, create the data handle and call
AddResource() on it.  It's a good idea to do a CurResFile() followed
sometime later by a UpdateResFile() if you've created a new resource; to
make sure it's written back to disk.

If you have questions about the specifics of any of this, I'd be glad to help.

dEVoN

- ------------------------------------------------------------------------
Devon Hubbard                                                Silicon Pilot
[e-mail]               Apple Guide Team         Apple Computer, Inc

+++++++++++++++++++++++++++

>From [e-mail] (Peter Bromley)
Date: Sat, 08 Jul 1995 18:32:13 +1200
Organization: ADInstruments

In article <[e-mail]>,
[e-mail] (Bill Hubauer) wrote:

> In article <[e-mail]>,
> [e-mail] (Clive Wilson) wrote:
>
> > Is there any easy way of having a small number of preferences stored in
> > the resource fork of an application?
> >
> > I'm using THINK Pascal and really don't want to have to have the hassle of
> > hunting the Preferences folder for my prefs. In any case it's more robust
> > having them located with their application.
> >
> > If there is a way of doing this, I would be really grateful if someone
> > could suggest some means of doing it.
> >
> > Many thanks in anticipation,
>
>
> Maybe I'm silly, but this is how I (and most everyone I work with) view
> resources as preferences:

Yes - very silly. You should treat the application as writable for
registration purposes only - although some applications I know dont even
try that either! The application could be locked or sharable or located on
a locked volume. No writee!

The place for preferences is the preferences file, the place for the
preferences file is in the preferences folder, and you dont create one
until the user changes a preference!!!

>
> From exprience, I do not trust the resource manager to write resources.
> Anytime I have written a program that writes resources (for preferences or
> whatever), The resource fork has eventually become corrupted.  (Have you
> ever had a tech support person tell you to "try trashing your prefs and
> restart"?)

Preference file resource forks get corrupted for one reason!!! Programmers
forget to call

        ***UpdateResFile***

after writing the resource, and sooner or later (when your Mac dies - for
whatever reason) the preferences file is dead in the water! UpdateResFile
is really essential if you want the resource map in the file to match the
resource map in memory.

>
> I view resources as READ ONLY.....

Only because you're paranoid about trashed preferences files. Hell,
resources used to make up 90% of early data files, we still store lots of
thing in resources in ours.

> ....  I would strongly recomend storing your
> preferences in the data fork.
>

Its easier and more standard to use resources for things like preferences
but, hey, if you want to use the Data Fork, go for it.

--
Peter Bromley                                  ([e-mail])
ADInstruments, Dunedin, New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Mark Chrisman)
Date: Sun, 09 Jul 1995 05:45:57 -0700
Organization: University of California, Davis

In article <[e-mail]>,
[e-mail] (Bill Hubauer) wrote:

>
> From exprience, I do not trust the resource manager to write resources.
> Anytime I have written a program that writes resources (for preferences or
> whatever), The resource fork has eventually become corrupted.  (Have you
> ever had a tech support person tell you to "try trashing your prefs and
> restart"?)
>

Yes, and it really annoys me, because it's nothing more than bad
programming.  A program should detect the error and trash the prefs
automatically.  And the error-checking should be there whether you're
using a data fork or a resource fork.

--
Mark Chrisman

+++++++++++++++++++++++++++

>From [e-mail] (Mark Chrisman)
Date: Sun, 09 Jul 1995 05:47:59 -0700
Organization: University of California, Davis

In article <mouser-0707950819520001@204.191.6.123>, [e-mail]
(Martin-Gilles Lavoie) wrote:

>
> Storing prefs in your app would be unadvisable for many reasons....

Here's another reason:  would you rather back up a 2 Meg application or a
2 K preference file?

--
Mark Chrisman

+++++++++++++++++++++++++++

>From [e-mail] (Jim Nash)
Date: 9 Jul 1995 19:03:41 GMT
Organization: SRS

In article <[e-mail]>, [e-mail]
(Peter Bromley) wrote:

> Its easier and more standard to use resources for things like preferences
> but, hey, if you want to use the Data Fork, go for it.

If you are using a separate file for preferences it makes sence to use the
data fork, but I have used both on different occations.  I used the data
fork for duplicating an exact image of a binary data structure.  It takes
five lines to do this:

  if size or version number changed:
    delete old
    create new
  open
  write
  close

I used string resources when I wanted the preference file to be forward
and backward compatible with different versions of my program.  This was
more complicated to write, so I wrote a small set of procedures to make it
easy.  Then I store value pairs (name = value).

- Jim

____________________________________________________________________
James W. Nash, Synergistic Research Systems
4409 Mahan Court, Silver Spring, MD 20906, USA
[phone], fax: [phone]
____________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Thu, 13 Jul 95 00:15:39 +0100
Organization: Network Analysis Ltd


In article <[e-mail]>
(comp.lang.pascal.mac,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.hel
p), [e-mail] (Bill Hubauer) writes:

> >From exprience, I do not trust the resource manager to write resources.
> Anytime I have written a program that writes resources (for preferences or
> whatever), The resource fork has eventually become corrupted.  (Have you
> ever had a tech support person tell you to "try trashing your prefs and
> restart"?)

Oh, c'mon; prefs files get trashed because some appls leave the prefs
files open and in the event of a crash any open file has a good
chance of being trashed. There's no law that says that you *must*
leave the prefs file open - you can read in the prefs, close the
file, and re-open it when the user changes something. The data fork
can get trashed in just the same way...

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!eu.britain.net!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Sun, 16 Jul 1995 15:34:17 -0700
Organization: BW Software

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>
> (comp.lang.pascal.mac,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.hel
> p), [e-mail] (Bill Hubauer) writes:
>
> > >From exprience, I do not trust the resource manager to write resources.
> > Anytime I have written a program that writes resources (for preferences or
> > whatever), The resource fork has eventually become corrupted.  (Have you
> > ever had a tech support person tell you to "try trashing your prefs and
> > restart"?)
>
> Oh, c'mon; prefs files get trashed because some appls leave the prefs
> files open and in the event of a crash any open file has a good
> chance of being trashed. There's no law that says that you *must*
> leave the prefs file open - you can read in the prefs, close the
> file, and re-open it when the user changes something. The data fork
> can get trashed in just the same way...


     I agree.  I've used the resource fork for my prefs and have yet to
see anything corrupted.  On top of what was mentioned above, I notice some
people (still) have a problem with locking handles; even though just about
every tech note and book stresses it.  Try to be neat and tidy (i.e.
proper error checking and use of handles and pointers) and you won't have
these problems.
Nyah nyah...

--
"Don't flip me off!  I'll have you fuckin' killed!" - True Romance
Eric A. Drumbor
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Mon, 17 Jul 1995 01:31:38 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Eric A. Drumbor) writes:
>In article <[e-mail]>,
>[e-mail] wrote:
>> In article <[e-mail]>
>> (comp.lang.pascal.mac,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.hel
>> p), [e-mail] (Bill Hubauer) writes:
>>
>> > >From exprience, I do not trust the resource manager to write resources.
>> > Anytime I have written a program that writes resources (for preferences or
>> > whatever), The resource fork has eventually become corrupted.  (Have you
>> > ever had a tech support person tell you to "try trashing your prefs and
>> > restart"?)

     I assume you mean the resource fork of a Preferences file, not the
resource fork of the application itself.  Writing into an application's
file is obnoxious; it might be locked, it might be on a read-only
medium, or virus protection software might think a virus is doing it.
And if anything goes wrong, the application gets trashed.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Glenn T. Lael)
Date: Tue, 18 Jul 1995 08:44:27 -0500
Organization: Liberty Mutual I/S


> In article <[e-mail]>,
> [e-mail] (Bill Hubauer) wrote:
>
> > In article <[e-mail]>,
> > [e-mail] (Clive Wilson) wrote:
> >
> > > Is there any easy way of having a small number of preferences stored in
> > > the resource fork of an application?
> > >
> > > I'm using THINK Pascal and really don't want to have to have the hassle of
> > > hunting the Preferences folder for my prefs. In any case it's more robust
> > > having them located with their application.
> > >
> > > If there is a way of doing this, I would be really grateful if someone
> > > could suggest some means of doing it.
> > >
> > > Many thanks in anticipation,
> >
> >
> > Maybe I'm silly, but this is how I (and most everyone I work with) view
> > resources as preferences:


As someone said somewhere else in this thread, preferences should go in
the preference file... but of course you knew that already ;,)

Take a look at Develop magazine, issue 18 (June 1994).  There is an
article by Gary Woodcock entitled "The Right way to Implement Preferences
Files".

The source library he talks about is probabily avaliable at http://
www.info.apple.com.

Hope this helps.

Glenn

Glenn T. Lael
Liberty Mutual Group
Portsmouth, NH

e-mail: [e-mail]

legaleese-> The opinions expressed hearin do not represent those of my employer.


Mister Blobbo Sez:
   3Remember, kids: Time is just Nature9s way of keeping
     everything from happening at once.2

+++++++++++++++++++++++++++

>From [e-mail] (Scott Lindsey)
Date: Sat, 22 Jul 1995 02:06:15 -0800
Organization: Claris Corp., Vancouver WA

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>
> (comp.lang.pascal.mac,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.hel
> p), [e-mail] (Bill Hubauer) writes:
>
> > >From exprience, I do not trust the resource manager to write resources.
> > Anytime I have written a program that writes resources (for preferences or
> > whatever), The resource fork has eventually become corrupted.  (Have you
> > ever had a tech support person tell you to "try trashing your prefs and
> > restart"?)
>
> Oh, c'mon; prefs files get trashed because some appls leave the prefs
> files open and in the event of a crash any open file has a good
> chance of being trashed. There's no law that says that you *must*
> leave the prefs file open - you can read in the prefs, close the
> file, and re-open it when the user changes something. The data fork
> can get trashed in just the same way...
>

Another possible reason for corrupting the resource fork is if you fail to
delete an existing resource before you write a new one with the same type
and ID.  This will result in multiple resources of the same type and ID
(i.e., a corrupt resource map).  Of course, if you always delete and
create a new prefs file from scratch, you're fine.  Also, if you always do
a GetResource first and simply modify its contents, if it already exist,
you're also fine.

--
Scott Lindsey <[e-mail]>
The opinions expressed herein are those of the author and not necessarily those of Claris, Apple, Adobe, Novell, IBM, General Motors, or any other company, government, or organization.

---------------------------

>From [e-mail] (Ken Flaton)
Subject: TextBox & Transfer Mode?!
Date: Mon, 17 Jul 1995 19:47:18 +0200
Organization: Zentrum fuer Neuroinformatik


Very briefly: is it possible to write text using TextBox() and get a srcOr
instead of what looks like a srcCopy for a transfer mode?  This is driving
me nuts...

Less briefly: how??

TIA,

--ken


*************************************
* Dr. Ken Flaton                    *
* Zentrum fuer Neuroinformatik      *
* Bochum, Germany                   *
*                                   *
* email: [e-mail]  *
*************************************

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 18 Jul 1995 04:13:40 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Ken Flaton) wrote:

<Very briefly: is it possible to write text using TextBox() and get a srcOr
<instead of what looks like a srcCopy for a transfer mode?  This is driving
<me nuts...
<
<Less briefly: how??
<
<TIA,
<
<--ken
<
<
<*************************************
<* Dr. Ken Flaton                    *
<* Zentrum fuer Neuroinformatik      *
<* Bochum, Germany                   *
<*                                   *
<* email: [e-mail]  *
<*************************************

TETextBox does an EraseRect() on the rect that you pass to it before it
draws the text.  The result is that whatever you ask it to do appears as
if you've used srcCopy.  DrawString will work for most uses of TETextBox.
TETexctBox does give you multiple lines if you need that.  The
justification it gives you can easily be obtained with DrawString.

Good luck,

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Aleksandar Totic)
Date: Tue, 18 Jul 1995 12:01:07 -0800
Organization: Netscape Communication Corporation

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> TETextBox does an EraseRect() on the rect that you pass to it before it
> draws the text.  The result is that whatever you ask it to do appears as
> if you've used srcCopy.  DrawString will work for most uses of TETextBox.
> TETexctBox does give you multiple lines if you need that.  The
> justification it gives you can easily be obtained with DrawString.

What is TETexctBox? I was not able to find any references to it in Inside Mac?

Aleks
--
Aleksandar Totic

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Tue, 18 Jul 1995 17:32:43 -0500
Organization: Metrowerks, Inc.

In article <[e-mail]>,
[e-mail] (Aleksandar Totic) wrote:

> In article <[e-mail]>,
> [e-mail] (Brian Stern) wrote:
>
> > TETextBox does an EraseRect() on the rect that you pass to it before it
> > draws the text.  The result is that whatever you ask it to do appears as
> > if you've used srcCopy.  DrawString will work for most uses of TETextBox.
> > TETexctBox does give you multiple lines if you need that.  The
> > justification it gives you can easily be obtained with DrawString.
>
> What is TETextBox? I was not able to find any references to it in Inside Mac?

MPTA says its in IM: Text, page 2-88. Feed it a rect and some text and it
puts said text in the rect.

   TETextBox(const void* text, short length, const Rect* box, short just);

-es

--
__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

Don't wake me up 'til my haircut comes back in style.

+++++++++++++++++++++++++++

>From [e-mail] (Peter Bromley)
Date: Wed, 19 Jul 1995 13:18:33 +1200
Organization: ADInstruments

In article <[e-mail]>,
[e-mail] (Aleksandar Totic) wrote:

> In article <[e-mail]>,
> [e-mail] (Brian Stern) wrote:
>
> What is TETextBox? I was not able to find any references to it in Inside Mac?
>

TETextBox is TextBox in new interface clothes. I have wriiten a routine we
use when doing mode aware text drawing. Readers of csmph might find it
useful. Pascal only, sorry. It is a little careless about errors but
should be safe enuf.

Here 'tis:

Procedure TETextBoxMode (   text    : Ptr;
                            length  : LongInt;
                            box     : Rect;
                            mode,
                            just    : Integer);

Var
    theTE       : TEHandle;
    oldMode,
    atPos,
    last,
    index,
    next,
    width       : Integer;
    fontStuff   : FontInfo;


{TETextBoxMode} begin
    if (mode = srcCopy) then
        TETextBox(text, length, box, just)
    else begin
        theTE := TENew(box, box);
{$IFC Undefined NewInterfaces}
        oldMode := thePort^.txMode;
{$ELSEC}
        oldMode := qd.thePort^.txMode;
{$ENDC}
        TextMode(mode);
        if (theTE <> nil) then begin
            TESetAlignment(just, theTE);
            TESetText(text, length, theTE);
            TECalText(theTE);
            GetFontInfo(fontStuff);
            atPos := box.Top + fontStuff.leading + fontStuff.ascent;
            last := 0;
            for index := 1 to theTE^^.nLines do begin
                if (index = theTE^^.nLines) then    { bug in TE means
lineStarts[nLines] may be unreliable }
                    next := length
                else
                    next := theTE^^.lineStarts[index];
                width := TextWidth(text, last, next - last);
                with box do
                    if (just = TEJustCenter) then
                        MoveTo((Left + Right - width) div 2, atPos)
                    else if (just = TEJustRight) then
                        MoveTo(Right - 1 - width, atPos)
                    else
                        MoveTo(Left, atPos);
                DrawText(text, last, next - last);
                atPos := atPos + theTE^^.lineHeight;
                last := next;
                end;
            TEDispose(theTE);
            end;
        TextMode(oldMode);
        end;
    end;

--
Peter Bromley                                  ([e-mail])
ADInstruments, Dunedin, New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (JWWalker)
Date: 19 Jul 1995 01:35:38 -0400
Organization: America Online, Inc. (1-800-827-6364)

Aleksandar Totic wrote:

> What is TETexctBox? I was not able to find any references to it in
> Inside Mac?

I daresay it's a misspelling of TETextBox.   I notice that two other
people who responded to your message silently fixed the error without
considering that it might have been the cause of your confusion.

You might want to look up the article "The TextBox You've Always Wanted"
in _develop_ magazine.  Sorry, I don't know what issue.
 -- Jim Walker

+++++++++++++++++++++++++++

>From Maf Vosburgh <[e-mail]>
Date: 19 Jul 1995 15:14:46 GMT
Organization: MMC

In article <[e-mail]> Ken
Flaton, [e-mail] writes:
>Very briefly: is it possible to write text using TextBox() and get a srcOr
>instead of what looks like a srcCopy for a transfer mode?  This is driving
>me nuts...

Just install a QuickDraw bottleneck temporarily to suppress the
EraseRect.


// takes a c string

void TextBoxOnBackground(char *s, Rect *r, short justification)
{
        CQDProcs        myProcs;
        CQDProc         *oldProcs = qd.thePort->grafProcs;

        SetStdCProcs(&myProcs);
        myProcs.rectProc =  = NewQDRectProc(VoidStdRect);
        qd.thePort->grafProcs = &myProcs;

        TextBox(s, strlen(s), r, justification);

        qd.thePort->grafProcs = oldProcs;
        DisposeRoutineDescriptor((UniversalProcPtr)myProcs.rectProc);
}

pascal void     VoidStdRect(GrafVerb verb, Rect *r)
{
                // Do nothing at all.
}





Maf Vosburgh
- -------------------------------------------------------------
Real QT experts just use MoviePlayer, Dumpster & ConvertToMovie.
Real C programmers use [0]-> (and it's called "sprong").

+++++++++++++++++++++++++++

>From Ben Hekster <[e-mail]>
Date: 20 Jul 1995 04:41:49 GMT
Organization: NetVision USENET Site.

In article <[e-mail]> Ken
Flaton, [e-mail] writes:
> Very briefly: is it possible to write text using TextBox() and get a
srcOr
> instead of what looks like a srcCopy for a transfer mode?  This is
driving
> me nuts...

For some reason TEUpdate does an EraseRect on the destination even when
the mode is srcOr.  Two ways I know of fixing this are to either
temporarily patch out EraseRect or replace the QD bottleneck procedure
around the call to TEUpdate (or TextBox).  I've personally only tried the
former, but I know of someone who did the bottleneck thing, so both
'solutions' seem to work.

Ben

+++++++++++++++++++++++++++

>From [e-mail] (Scott E. Lasley)
Date: Thu, 27 Jul 1995 15:56:39 -0400
Organization: University of Maryland Space Physics Group

you can also find code for a better TextBox in issue 9 of develop magazine.
if you don't subscribe to develop, look on Apple's ftp sites for code from
develop.  i you acan also oder back issues from [e-mail].

hope this helps,


scott lasley   [e-mail], http://space.umd.edu
"Cheating is bad.  Richard Basehart is good."  MST3K


---------------------------

>From [e-mail] (Roy Lovejoy)
Subject: WOW. Was: Man, is image manipulation ugly in Pascal!
Date: Sat, 29 Jul 1995 01:31:47 GMT
Organization: Adept Solutions

In article <catambay-2507950753260001@129.197.23.12>, [e-mail]
(Bill the Cat) wrote:

> In article <[e-mail]>,
> [e-mail] (Quinn "The Eskimo!") wrote:
>
> > In article <[e-mail]>, [e-mail]
> > (Roy Lovejoy) wrote:
> >
> > >or better yet, avoid the strip address problem
> > >
> > >{
> > >char  *p = initial_location;
> > >long count = num_bytes;
> > >
> > >   while (count--)
> > >      *p = ~*p++;
> > >}
> >
>
> What are all those funky looking symbols?  Reminds me of APL.

Umm..I don't see any funky symbols... Looks like standard K&R.
Oh.. you must mean the +. It adds two expressions together. It's pretty handy.
Oh, do you mean the -. It subtracts.
The * ?? It's like a ^ in pascal. (you might never have derefernced a pointer.)
The ~ ?? It's like BITOR()..only easier to type, without closing parenthesis.
HMMM... you must have had line noise if you saw any funky symbols...


> No flames here.  A standing ovation would be more in line.

Yeah. right.

Its strange that someone who even knows of the EXISTANCE of APL, would be
'amazed' by textbook C.

Note the smiley, saved for last -> ;)
- -------------------------------------------------------------------
Roy Lovejoy          PHONE: [phone]  INET:[e-mail]
Pixel PooBah           FAX: [phone]   ALINK: ............. adept
Adept Solutions                              CIS: ........ 72447,1447
524 Avenida Verde                         eWorld: ........ adeptsolns
San Marcos CA 92069                          AOL: ........ adeptsolns
- -------------------------------------------------------------------

---------------------------

>From [e-mail] (Dan Peterson)
Subject: [ANN][PTR] Advanced Color Imaging for Toolbox Assistant
Date: Wed, 26 Jul 1995 09:17:02 -0700
Organization: Apple Developer Press

Sorry if you already saw this announcement, but I wasn't sure that it
actually got posted.

Now available for the Macintosh Programmer's Toolbox Assistant:

Advanced Color Imaging Reference

This new database for the Macintosh Programmer's Toolbox Assistant
contains information fr these often requested managers that were
previously unavailable:
   * Palette Manager
   * Color Manager
   * Color Picker Manager
   * ColorSync

As always, if you are a current user of Macintosh Programmer's Toolbox
Assistant, you can download these new files from our web site at:

http://www.info.apple.com/dev/MPTA.html


If you aren't a current user of the Macintosh Programmer's Toolbox
Assistant, it is available from your local bookstore, or through APDA at
1-800-282-APDA.

As always, your comments and suggestions on Toolbox Assistant are always
welcome. Send them to [e-mail].

Hope this helps!

Dan Peterson,
Developer Press,
Apple Computer, Inc.

---------------------------

End of C.S.M.P. Digest
**********************